Artifact: Business Object Model

Business Object Model	The business object model is an object model describing the realization of business use cases.
UML representation:	Model, stereotyped as ½business object model╗.
Worker:	Business-Process Analyst
Optionality:	Can be excluded.
Sample Reports:	Report: Business Object Model Survey
More information:	Checkpoints: Business Object Model Report: Business Object Model Survey Guidelines: Business Object Model Guidelines: Association in the Business Object Model Guidelines: Aggregation in the Business Object Model Guidelines: Generalization in the Business Object Model Guidelines: Class Diagram in the Business Object Model Guidelines: Collaboration Diagram in the Business Object Model Guidelines: Sequence Diagram in the Business Object Model Guidelines: Statechart Diagram in the Business Object Model
Purpose Properties Timing Responsibility Tailoring

Input to Activities: Architectural Analysis Capture a Common Vocabulary Define Automation Requirements Define Business Architecture Define Project Organization and Staffing Detail a Business Entity Detail a Business Worker Develop Vision Find Actors and Use Cases Maintain Business Rules Plan Phases and Iterations Review Business Object Model

Output from Activities: Find Business Workers and Entities Review Business Object Model

Purpose

The following people use the business object model:

• The business-process analyst is responsible for the integrity of the model.
• The business designer documents details about responsibilities people carry and "things" produced or used by the business in this model.
• The system analyst uses this model as input for identifying system actors and system use cases.
• The designer uses this model as input for identifying classes in the analysis & design models.

Properties

Timing

A business object model is created during inception and finalized during the elaboration phase.

Responsibility

A business-process analyst is responsible for the integrity of the business object model, ensuring that:

• The organization units correctly represent the structure of the business.
• The collection of business workers together cover all responsibilities in the business.
• The collection of business entities together cover all "things" produced and used in the business.

Tailoring

We have identified three main variants for tailoring the business object model: 

• Build an "incomplete" business object model, often called domain modeling. 
• Build two versions of the business object model, the "as-is" and the "to-be" model. 
• Exclude the business object model. 

See also Guidelines: Target-Organization Assessment. 

Domain Modeling

You can choose to develop an "incomplete" business object model, focusing on explaining "things" and products important to the business domain. Such a model does not include the responsibilities people will carry, it only describes the information content of the organization. This is often referred to as a domain model. In such a case, you would stereotype the model as ½domain model╗ instead of ½business object model╗.

As-Is and To-Be Models

If the purpose of the business modeling effort is to do business reengineering, you should consider building two variants of the business object model: one that shows the current situation (as-is), and one that shows the envisioned new processes (to-be). 

The as-is version of the business object model is simply an inventory of the business use-case realizations. The elements of the business object model are not described in any detail, typically brief descriptions are sufficient. The business use-case realizations can be documented with simple activity diagram, where swimlanes correspond to elements of the business object model. 

Exclude the Business Object Model

If the business domain is well-understood by all members of the project team, the benefits of developing a business object model are significantly diminished. Where this occurs, the business object model may be omitted entirely.

The business object model is a way of expressing the business processes in terms of responsibilities, deliverables, and collaborative behavior. Not producing a business object model means you run the risk that developers will only give superficial attention to the way business is done. They will do what they know best, which is to design and create software in absence of business process knowledge.  The result can be that the systems that are built do not support the needs of the business. 

Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Rational Unified Process